The v0.37.0 Release and Docker workflows failed on both Linux build paths: the semantic search merge (#999) pulled in github.com/asg017/sqlite-vec-go-bindings/cgo (via go.kenn.io/kit/vector/sqlitevec), whose C sources #include "sqlite3.h". GitHub's hosted ubuntu/macos/windows images provide SQLite headers, but the manylinux_2_28 release containers and the golang:bookworm Docker build stage do not, so go build died with fatal error: sqlite3.h: No such file or directory. That blocked the CLI release assets and the PyPI publish.

Instead of installing distro headers, both Linux build paths now compile sqlite-vec against the header of the exact SQLite amalgamation bundled and statically linked by mattn/go-sqlite3 (sqlite3-binding.h, currently 3.53.2), exposed via CGO_CFLAGS. This keeps the compile-time header and the linked library at the same version everywhere. It also avoids a silent behavior difference: manylinux_2_28 (AlmaLinux 8) ships SQLite 3.26 headers, and sqlite-vec compiles out its sqlite3_vtab_in support when built against headers older than 3.38, which would have made PyPI wheels behave differently from every other build.

Reviewers should look at the new header-staging step in .github/workflows/release.yml (build-linux) and the equivalent RUN/ENV pair in Dockerfile. macOS and Windows builds are unchanged; they already build against SDK/toolchain headers newer than 3.38.